Qu'est-ce que la gestion des incidents ?

La gestion des incidents est le processus utilisé par les équipes développement et des opérations informatiques pour répondre à un événement imprévu ou à une interruption de service, et rétablir le service dans son état opérationnel.

Chez Atlassian, , nous définissons un incident comme un événement ayant provoqué une perturbation ou une réduction de la qualité d’un service nécessitant une réponse d’urgence. À la place, les équipes qui adoptent les pratiques ITIL ou ITSM préfèrent le terme « incident majeur ».

Incidents are events of any kind that disrupt or reduce the quality of service (or threaten to do so). A business application going down is an incident. A crawling-but-not-yet-dead web server can be an incident, too. It’s running slowly and interfering with productivity. Worse yet, it poses the even-greater risk of complete failure. Incidents can vary widely in severity, ranging from an entire global web service crashing to a small number of users having intermittent errors. An incident is resolved when the affected service resumes functioning in its intended state. This includes only those tasks required to mitigate impact and restore functionality.

La gestion des incidents est l’un des processus les plus critiques qu’une organisation doit maîtriser. Les interruptions de service peuvent coûter cher à l’entreprise et les équipes ont besoin d’un moyen efficace pour réagir et résoudre rapidement ces problèmes. Les équipes ont besoin d’une méthode fiable pour hiérarchiser les incidents, les résoudre plus rapidement et fournir un meilleur service aux utilisateurs.

Lorsque les équipes sont confrontées à un incident, elles ont besoin d’un plan qui les aide à :

• Réagir efficacement afin de pouvoir récupérer rapidement.
• Communiquer clairement avec les clients, les parties prenantes, les Service Owners et les autres membres de l’organisation.
• Collaborer efficacement pour résoudre le ticket plus rapidement en équipe et éliminer les obstacles empêchant sa résolution.
• Apprendre continuellement en tirant des leçons de ces pannes et en les appliquant afin d’améliorer leurs services et d’affiner leurs processus futurs.

Chaque types d’entreprise a tendance à privilégier différents types de processus de gestion des incidents. Il n’existe pas de processus unique et universel : les différentes entreprises utilisent donc diverses approches.

De nombreuses équipes s’appuient sur un processus de gestion des incidents plus traditionnel, de type informatique, tel que celui décrit dans les certifications ITIL. D’autres équipes privilégient un processus de gestion des incidents plus proche de celui des ingénieurs chargés de la fiabilité des sites (SRE) ou du DevOps.

Un processus de gestion des incidents aide les équipes informatiques à enquêter, enregistrer et résoudre les interruptions ou pannes de service. Le flux de travail de gestion des incidents ITIL vise à réduire les temps d’arrêt et à minimiser l’impact des incidents sur la productivité des employés. À l’aide de modèles conçus pour gérer les incidents, vous pouvez créer un flux de travail de gestion des incidents reproductible, qui garantit que les équipes enregistrent, diagnostiquent et résolvent les incidents, tout en conservant une trace de leurs activités.

Le framework ITIL est principalement utilisé par les équipes informatiques qui gèrent les services au sein des entreprises. En général, les équipes prennent ce dont elles ont besoin dans ITIL (qui couvre presque tous les types d’incidents, de tickets et de processus auxquels les équipes informatiques peuvent être confrontées) et laissent le reste. ITIL est très utile lorsque les équipes doivent se concentrer sur l’instauration d’une culture de résolution active des problèmes. Les processus prescrits aident les équipes à suivre les incidents et les actions de manière cohérente, ce qui améliore les rapports et les analyses, et peut conduire à un service plus sain et à une équipe plus performante.

Un incident peut provenir de n’importe où : d’un employé, d’un client, d’un fournisseur, des systèmes de surveillance. Quelle que soit la source, les deux premières étapes sont simples : quelqu’un identifie un incident, puis quelqu’un l’enregistre. Ces journaux d’incidents (c’est-à-dire les tickets) comprennent généralement :

• Le nom de la personne qui signale l’incident
• La date et l’heure de signalement de l’incident
• Une description de l’incident (le composant en panne ou qui ne fonctionne pas correctement)
• Un numéro d’identification unique attribué à l’incident pour le suivi

Assignez une catégorie logique et intuitive (et une sous-catégorie, selon les besoins) à chaque incident. Cela vous permet d’analyser vos données pour rechercher des tendances et des schémas, une étape indispensable à une gestion efficace des problèmes et à la prévention d’incidents futurs.

Chaque incident doit se voir attribuer une priorité. Commencez par évaluer son impact sur l’entreprise, le nombre de personnes qui seront touchées, tout SLA applicable, ainsi que les répercussions potentielles en termes de finances, de sécurité et de conformité.  Comparez cet incident à tous les autres incidents ouverts pour déterminer sa priorité relative. Une bonne pratique consiste à définir vos niveaux de gravité et de priorité avant qu’un incident ne se produise, ce qui simplifie l’évaluation de la priorité pour les gestionnaires d’incidents. 

• Diagnostic initial : dans l’idéal, votre équipe de support de première ligne doit pouvoir suivre un incident du diagnostic à sa résolution. Cependant, si ce n’est pas possible, l’étape suivante consiste à consigner toutes les informations pertinentes et à les transmettre à l’équipe de niveau supérieur.
• Faire remonter les problèmes : l’équipe suivante consulte les données enregistrées et poursuit le processus de diagnostic. Si cette équipe ne parvient pas à diagnostiquer l’incident, elle le transmet à l’équipe suivante.
• Communiquer : l’équipe partage régulièrement des mises à jour avec les parties prenantes internes et externes concernées.
• Enquête et diagnostic : ce processus se poursuit jusqu’à ce que la nature de l’incident soit identifiée. Parfois, les équipes font appel à des ressources externes ou à d’autres membres du service pour les conseiller et les aider à trouver une solution.
• Résolution et récupération : au cours de cette étape, l’équipe établit un diagnostic et prend les mesures nécessaires pour résoudre l’incident. La récupération correspond simplement au temps nécessaire pour que les opérations soient entièrement rétablies, car certaines corrections (comme les correctifs de bugs, etc.) peuvent nécessiter des tests et un déploiement même après avoir identifié la solution appropriée.
• Clôture : si l’incident a été remonté, il est alors renvoyé au centre de services pour être clôturé. Pour assurer une qualité optimale et le bon déroulement du processus, seuls les employés du centre de services sont autorisés à clôturer les incidents. Le propriétaire de l’incident doit vérifier auprès de la personne qui a signalé l’incident que ce dernier a bien été résolu et qu’il peut effectivement être clôturé.

Avec une approche DevOps ou SRE en matière de gestion des incidents, l’équipe qui développe le service le gère et le répare également en cas de panne. Cette approche a connu un essor fulgurant parallèlement à la croissance des services cloud toujours disponibles, des applications Web accessibles dans le monde entier, des microservices et des « Softwares as a Service » (logiciels en tant que service).

De plus en plus, les logiciels dont vous dépendez dans votre vie privée et professionnelle ne sont pas hébergés sur un serveur situé au même endroit que vous. Il s’agit probablement d’une application accessible via Internet, déployée dans un Data Center pour des milliers, voire des millions d’utilisateurs à travers le monde. Pour les équipes chargées de gérer ces services, l’agilité et la rapidité sont primordiales. Tout temps d’arrêt peut affecter des milliers d’organisations, et pas seulement une seule.

L’un des avantages de l’approche « Vous le concevez, vous en êtes responsable » est qu’elle offre l’importante flexibilité dont les équipes Agiles ont besoin, mais cela peut également brouiller les responsabilités de chacun. Les équipes DevOps peuvent se sentir à l’aise et réussir avec des processus de développement moins structurés. Cependant, il est préférable de normaliser un ensemble de processus de base pour la gestion des incidents afin qu’il n’y ait aucun doute sur la manière de réagir en cas d’incident et que vous puissiez suivre les problèmes et rendre compte de leur résolution.

• Être d’astreinte à tour de rôle : plutôt que de laisser certains membres de l’équipe se spécialiser dans les astreintes, les équipes DevOps tournent généralement selon un planning d’astreinte dans lequel tous leurs membres partagent le fardeau d’être potentiellement réveillé en pleine nuit pour répondre à un incident.
• L’ingénieur qui a développé la fonctionnalité est la personne la mieux placée pour la corriger : l’idée centrale de la philosophie « Vous le concevez, vous en êtes responsable » est que les personnes les plus familières avec le service (les développeurs) sont les plus à même de corriger une panne.
• Développez rapidement, mais soyez responsable : si les ingénieurs savent qu’eux et leurs coéquipiers sont responsables en cas de panne, ils vous incitent d’autant plus à déployer un code de qualité.

Cette approche accélère les temps de réponse et garantit un retour d’informations plus rapide pour les équipes ayant besoin de savoir comment mettre en place un service fiable.

Pour en savoir plus sur l’approche très favorable au DevOps pour la gestion des incidents, consultez notre Manuel de gestion des incidents Atlassian.

La gestion des incidents ne se fait pas uniquement à l’aide d’un outil, mais grâce à une combinaison adéquate d’outils, de bonnes pratiques et de personnes. Voici quelques-unes des catégories d’outils les plus courantes pour une gestion efficace des incidents :

• Suivi des incidents : chaque incident doit être suivi et documenté afin que vous puissiez identifier les tendances et les comparer au fil du temps.
• Groupe de discussion : la communication textuelle en temps réel est essentielle pour diagnostiquer et résoudre l’incident en équipe. Elle permet également de disposer d’un ensemble complet de données pour analyser ultérieurement la réponse apportée.
• Chat vidéo : le chat vidéo vient souvent compléter le chat textuel. Le chat vidéo en équipe permet d’échanger sur les résultats et d’élaborer une stratégie de réponse.
• Système d’alerte : un outil tel que Jira Service Management s’intègre à votre système de surveillance et gère les rotations d’astreinte et les remontées de problèmes.
• Outil de documentation : un outil tel que Confluence peut capturer les documents relatifs à l’état des incidents et les analyses post-mortem.
• Statuspage : communiquer l’état d’avancement aux parties prenantes internes et aux clients via Statuspage permet à tout le monde de rester informé.